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Abstract 


Label Switched Paths (LSPs) set up in Multiprotocol Label Switching 
(MPLS) or Generalized MPLS (GMPLS) networks can be used to form links 
to carry traffic in those networks or in other (client) networks. 


Protocol mechanisms already exist to facilitate the establishment of 
such LSPs and to bundle traffic engineering (TE) links to reduce the 
load on routing protocols. This document defines extensions to those 
mechanisms to support identifying the use to which such LSPs are to 
be put and to enable the TE link endpoints to be assigned addresses 
or unnumbered identifiers during the signaling process. 


The mechanisms defined in this document deprecate the technique for 


= 


the signaling of LSPs that are to be used as numbered TE links 
described in RFC 4206. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6107. 
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1. Introduction and Problem Statement 


Traffic Engineering (TE) links in a Multiprotocol Label Switching 
(MPLS) or a Generalized MPLS (GMPLS) network may be constructed from 
Label Switched Paths (LSPs) [RFC4206]. Such LSPs are known as 
hierarchical LSPs (H-LSPs). 


The LSPs established in one network may be used as TE links in 
another network, and this is particularly useful when a server layer 
network (for example, an optical network) provides LSPs for use as TE 
links in a client network (for example, a packet network). This 
enables the construction of a multilayer network (MLN) [RFC5212]. 


When the number of TE links (created from LSPs or otherwise) between 
a pair of nodes grows large, it is inefficient to advertise them 
individually. This may cause scaling issues in configuration and in 
the routing protocols used to carry the advertisements. The solution 
(described in [RFC4201]) is to collect the TE links together and to 
advertise them as a single TE link called a link bundle. 
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These various mechanisms have proved to be very powerful in building 
dynamically provisioned networks, but, as set out later in this 
document, several issues have been identified during deployment with 
how LSPs are established and made available for use as H-LSPs or as 
components of a link bundle, and with how these links are advertised 
appropriately in an interior gateway protocol (IGP). These issues 
relate to how the LSP’s endpoints coordinate two things: the use to 
which the LSP is put and the identifiers of the endpoints. 


This document provides solutions to these issues by defining 
mechanisms so that the ends of signaled LSPs can exchange information 
about: 


- Whether the LSP is an ordinary LSP or an H-LSP. 

- In which IGP instances the LSP should be advertised as a link. 

—- How the client networks should make use of the new links. 

— Whether the link should form part of a bundle (and if so, which 
bundle). 

- How the link endpoints should be identified when advertised. 


This document deprecates one of the mechanisms defined in [RFC4206] 
for the signaling of LSPs that are to be used as numbered TE links 
(see Sections 1.3.6 and 1.4.6 for more details), and provides 
extensions to the other mechanisms defined in [RFC4206] so that the 
use to which the new LSP is to be put may be indicated during 
signaling. It also extends the mechanisms defined in [RFC3477] for 
signaling unnumbered TE links. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


1.1. Background 
1.1.1. Hierarchical LSPs 


[RFC3031] describes how MPLS labels may be stacked so that LSPs may 
be nested with one LSP running through another. This concept of 
H-LSPs is formalized in [RFC4206] with a set of protocol mechanisms 
for the establishment of an H-LSP that can carry one or more other 
LSPs. 


[RFC4206] goes on to explain that an H-LSP may carry other LSPs only 
according to their switching types. This is a function of the way 
labels are carried. In a packet switch capable (PSC) network, the 
H-LSP can carry other PSC LSPs using the MPLS label stack. In non- 
packet networks where the label is implicit, label stacks are not 
possible, and H-LSPs rely on the ability to nest switching 
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technologies. Thus, for example, a lambda switch capable (LSC) LSP 
can carry a time-division multiplexing (TDM) LSP, but cannot carry 
another LSC LSP. 


Signaling mechanisms defined in [RFC4206] allow an H-LSP to be 
treated as a single hop in the path of another LSP (i.e., one hop of 
the LSP carried by the H-LSP). This mechanism is known as "non- 
adjacent signaling". 


1.1.2. LSP Stitching Segments 


LSP stitching is defined in [RFC5150]. It enables LSPs of the same 
switching type to be included (stitched) as hops in an end-to-end 
LSP. The stitching LSP (S-LSP) is used in the control plane in the 
same way as an H-LSP, but in the data plane the LSPs are stitched so 
that there is no label stacking or nesting of technologies. Thus, an 
S-LSP must be of the same switching technology as the end-to-end LSP 
that it facilitates. 


1.1.3. Private Links 


An H-LSP or S-LSP can be used as a private link. Such links are 
known by their endpoints, but are not more widely known and are not 
advertised by routing protocols. They can be used to carry traffic 


between the endpoints, but are not usually used to carry traffic that 
is going beyond the egress of the LSP. 


1.1.4. Routing Adjacencies 


A routing adjacency is formed between two IGP speakers that are 
logically adjacent. In this sense, ’logically adjacent’ means that 
the routers have a protocol tunnel between them through which they 
can exchange routing protocol messages. The tunnel is also usually 
available for carrying IP data although a distinction should be made 
in GMPLS networks between data-plane traffic and control-plane 
traffic. 


Routing adjacencies for forwarding data traffic are only relevant in 
PSC networks (i.e., IP/MPLS networks). 


1.1.5. Forwarding Adjacencies 
A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link 
created from an LSP and advertised in the same instance of the 


control plane that advertises the TE links from which the LSP is 
constructed. The LSP itself is called an FA-LSP. 


Shiomoto & Farrel Standards Track [Page 5] 


RFC 6107 Procedures for H-LSPs February 2011 


Thus, an H-LSP or S-LSP may form an FA such that it is advertised as 
a TE link in the same instance of the routing protocol as was used to 
advertise the TE links that the LSP traverses. 


As observed in [RFC4206], the nodes at the ends of an FA would not 
usually have a routing adjacency. 


1.1.6. Client/Server Networks 


An LSP may be created in one network and used as a link (sometimes 


called a virtual link) in another network [RFC5212]. In this case, 
the networks are often referred to as server and client networks, 
respectively. 


The server network LSP is used as an H-LSP or an S-LSP as described 
above, but it does not form an FA because the client and server 
networks run separate instances of the control-plane routing 
protocols. 


The virtual link may be used in the client network as a private link 
or may be advertised in the client network IGP. Additionally, the 
link may be used in the client network to form a routing adjacency 
and/or as a TE link. 


1.1.7. Link Bundles 


[RFC4201] recognizes that a pair of adjacent routers may have a large 
number of TE links that run between them. This can be a considerable 
burden to the operator who may need to configure them and to the IGP 
that must distribute information about each of them. A TE link 
bundle is defined by [RFC4201] as a TE link that is advertised as an 
aggregate of multiple TE links that could have been advertised in 
their own right. All TE links that are collected into a TE link 
bundle have the same TE properties. 


Thus, a link bundle is a shorthand that improves the scaling 
properties of the network. 


Since a TE link may, itself, be an LSP (either an FA or a virtual 
link), a link bundle may be constructed from FA-LSPs or virtual 
links. 
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1.2. Desired Function 


It should be possible to signal an LSP and automatically coordinate 
its use and advertisement in any of the ways described in Section 1.3 
with minimum involvement from an operator. The mechanisms used 
should be applicable to numbered and unnumbered links and should not 
require implementation complexities. 


1.3. Existing Mechanisms 


This section briefly introduces existing protocol mechanisms used to 
satisfy the desired function described in Section 1.2. 


1.3.1. LSP Setup 


Both unidirectional LSPs and bidirectional LSPs are signaled from the 
ingress label switching router (LSR) to the egress LSR. That is, the 
ingress LSR is the initiator, and the egress learns about the LSP 
through the signaling protocol [RFC3209] [RFC3473]. 


1.3.2. Routing Adjacency Establishment and Link State Advertisement 


Although hosts can discover routers (for example, through ICMP 
[RFC1256]), routing adjacencies are usually configured at both ends 
of the adjacency. This requires that each router know the identity 
of the router at the other end of the link connecting the routers, 
and know that the IGP is to be run on this link. 


Once a routing adjacency has been established, a pair of routers may 
use the IGP to share information about the links available for 
carrying IP traffic in the network. 


Suitable routing protocols are OSPF version 2 [RFC2328], OSPF version 
3 [RFC5340], and IS-IS [RFC1195]. 


1.3.3. TE Link Advertisement 


Extensions have been made to IGPs to advertise TE link properties 
([RFC3630], [RFC5329], [RFC5305], [RFC5308], and [ISIS-IPV6-TE]) and 
also to advertise link properties in GMPLS networks ([RFC4202], 
[RFC4203], and [RFC5307]). 


TE link advertisement can be performed by the same instance of the 
IGP as is used for normal link state advertisement, or can use a 
separate instance. Furthermore, the ends of a TE link advertised in 
an IGP do not need to form a routing adjacency. This is particularly 
the case with FAs as described in Section 1.1.5. 
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1.3.4. Configuration and Management Techniques 


LSPs are usually created as the result of a management action. This 
is true even when a control plane is used: the management action is a 
request to the control plane to signal the LSP. 


If the LSP is to be used as an H-LSP or S-LSP, management commands 
can be used to install the LSP as a link. The link must be defined, 
interface identifiers allocated, and the endpoints configured to know 
about (and advertise, if necessary) the new link. 


If the LSP is to be used as part of a link bundle, the operator must 
decide which bundle it forms part of and ensure that information is 
configured at the ingress and egress, along with the necessary 
interface identifiers. 


These mechanisms are perfectly functional and quite common in MLNs, 
but require configuration coordination and additional management. 
They are open to user error and misconfiguration that might result in 
the LSP not being used (a waste of resources) or the LSP being made 
available in the wrong way with some impact on traffic engineering. 


1.3.5. Signaled Unnumbered FAs 


[RFC3477] describes how to establish an LSP and to make it available 
automatically as a TE link in the same instance of the routing 
protocol as advertises the TE links it traverses, using IPv4-based 
unnumbered identifiers to identify the new TE link. That is, 
[RFC3477] describes how to create an unnumbered FA. 


The mechanism, as defined in Section 3 of [RFC3477], is briefly as 
follows: 


- The ingress of the LSP signals the LSP as normal using a Path 
message, and includes an LSP_TUNNEL_INTERFACE_ID object. The 
LSP_TUNNEL_INTERFACE_ID object identifies: 

- The sender’s LSR Router ID 
- The sender’s interface ID for the TE link being created 


- The egress of the LSP responds as normal to accept the LSP and set 
it up, and includes an LSP_TUNNEL_INTERFACE_ID object. The 
LSP_TUNNEL_INTERFACE_ID object identifies: 

- The egress’s LSR Router ID 
- The egress’s interface ID for the TE link being created. 
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- Following the exchange of the Path and Resv messages, both the 
ingress and the egress know that the LSP is to be advertised as a 
TE link in the same instance of the routing protocol as was used to 

advertise the TE links that it traverses, and also know the 
unnumbered interface identifiers to use in the advertisement. 


[RFC3477] does not include mechanisms to support IPv6-based 
unnumbered identifiers, nor IPv4 or IPv6 numbered identifiers. 


1.3.6. Establishing Numbered FAs through Signaling and Routing 


[RFC4206] describes procedures to establish an LSP and to make it 
available automatically as a TE link that is identified using IPv4 
addresses in the same instance of the routing protocol as advertises 
the TE links it traverses (that is, as a numbered FA). 


The mechanism, as defined in [RFC4206], is briefly as follows: 


- The ingress of the LSP signals the LSP as normal using a Path 
message, and sets the IPv4 tunnel sender address to the IP address 
it will use to identify its interface for the TE link being 
created. This is one address from a /31 pair. 


- The egress of the LSP responds as normal to accept the LSP and set 
it up. It infers the address that it must assign to identify its 
interface for the TE link being created as the partner address of 
the /31 pair. 


- The ingress decides whether the LSP is to be advertised as a TE 
link (i.e., as an FA). If so, it advertises the link in the IGP in 
the usual way. 


- If the link is unidirectional, nothing more needs to be done. If 
the link is bidirectional, the egress must also advertise the link, 
but it does not know that advertisement is required as there is no 
indication in the signaling messages. 


- When the ingress’s advertisement of the link is received by the 
egress, it must check to see whether it is the egress of the LSP 
that formed the link. Typically, this means the egress: 

- Checks to see if the link advertisement is new. 

- Checks to see if the Link-ID address in the received 
advertisement matches its own TE Router ID. 

- Checks the advertising router ID from the advertisement against 
the ingress address of each LSP for which it is the egress. 

- Deduces the LSP that has been advertised as a TE link and issues 
the corresponding advertisement for the reverse direction. 
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It is possible that some reduction in processing can be achieved by 
mapping based on the /31 pairing, but nevertheless, there is a fair 
amount of processing required, and this does not scale well in large 
networks. 


Note that this document deprecates this procedure as explained in 
Section 1.4.6. 


No explanation is provided in [RFC4206] of how to create numbered 
IPv6 FAs. 


1.4. Overview of Required Extensions 


This section provides a brief outline of the required protocol 
extensions. 


1.4.1. Efficient Signaling of Numbered FAs 


The mechanism described in Section 1.3.6 is inefficient. The egress 
must wait until it receives an advertisement from the ingress before 
it knows that the LSP is to be installed as a TE link and advertised 
as an FA. Further, it must parse all received advertisements to 
determine if any is the trigger for it to advertise an FA. 


An efficient signaling mechanism is required so that the egress is 
informed by the ingress during LSP establishment. 


1.4.2. LSPs for Use as Private Links 


There is currently no mechanism by which an ingress can indicate that 
an LSP is set up for use as a private link. Any attempt to make it a 
link would currently cause it to be advertised as an FA. 


A signaling mechanism is needed to identify the use to which an LSP 
is to be put. 


1.4.3. Signaling an LSP for Use in Another Network 


The existing signaling/routing mechanisms are designed for use in the 
creation of FAs. That is, the TE link created is advertised in the 
single IGP instance. 


The numbered TE link mechanism (Section 1.3.6) could, in theory, be 
used in an MLN with multiple IGP instances if the addressing model is 
kept consistent across the networks, and if the egress searches all 
advertisements in all IGP instances. However, this is complex and 
does not work for unnumbered interfaces. 
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A signaling mechanism is required to indicate in which IGP instance 
the TE link should be advertised. 


1.4.4. Signaling an LSP for Use in a Link Bundle 


A signaling mechanism is required to indicate that an LSP is intended 
to form a component link of a link bundle, and to identify the bundle 
and the IGP instance in which the bundle is advertised. 


1.4.5. Support for IPv4 and IPv6 


The protocol mechanisms must support IPv4 and IPv6 numbered and 
unnumbered TE links. 


1.4.6. Backward Compatibility 


The existing protocol mechanisms for unnumbered FAs as defined in 
[RFC4206] and [RFC3477] must continue to be supported, and new 
mechanisms must be devised such that their introduction will not 
break existing implementations or deployments. 


Note that an informal survey in the CCAMP working group established 
that there are no significant deployments of numbered FAs established 
using the technique described in [RFC4206] and set out in Section 
1.3.6. Therefore, this document deprecates this procedure. 


2. Overview of Solution 


This section provides an overview of the mechanisms and protocol 
extensions defined in this document. Details are presented in 
Section 3. 


2.1. Common Approach for Numbered and Unnumbered Links 
The LSP_TUNNEL_INTERFACE_ID object [RFC3477] is extended for use for 
all H-LSPs and S-LSPs whether they form numbered or unnumbered IPv4 


or IPv6 links. Different Class Types of the object identify the 
address type for which it applies. 
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2.2. LSP Usage Indication 


The LSP_TUNNEL_INTERFACE_ID object is given flags in a new Actions 
field to say how the LSP is to be used. The following categories are 
supported: 


-— The LSP is used as an advertised TE link. 

— The LSP is used to form a routing adjacency. 

—- The LSP is used to form an advertised TE link and a routing 
adjacency. 

- The LSP forms a private link and is not advertised. 

-— The LSP is used as part of a link bundle. 

- The LSP is used as a hierarchical LSP or a stitching segment. 


2.3. IGP Instance Identification 


An optional TLV is added to the LSP_TUNNEL_INTERFACE_ID object to 
identify the IGP instance into which the link formed by the LSP is to 
be advertised. If the TLV is absent and the link is to be advertised 
as indicated by the Actions field, the link is advertised in the same 
instance of the IGP as was used to advertise the TE links it 
traverses. 


2.4. Link Bundle Identification 
When an LSP is to be used as a component link of a link bundle, the 
LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how 
the bundle is addressed and used, and a new TLV indicates the 
component link identifier for the link that the LSP creates. 

2.5. Backward Compatibility 
Backward compatibility has three aspects. 
- Existing mechanisms for unnumbered FAs described in [RFC3477] and 


[RFC4206] must continue to work, so that ingress nodes do not have 
to be updated when egresses are updated. 


- Existing mechanisms for establishing numbered FAs described in 
[RFC4206] are safely deprecated by this document, as they are not 
significantly deployed. 


- New mechanisms must be gracefully rejected by existing egress 


implementations so that egress nodes do not have to be updated when 
ingresses are updated. 
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3. Mechanisms and Protocol Extensions 


This section defines protocol mechanisms and extensions to achieve 
the function described in the previous section. 


3.1. LSP_TUNNEL_INTERFACE_ID Object 


The principal signaling protocol element used to achieve all of the 
required functions is the LSP_TUNNEL_INTERFACE_ID object defined in 
[RFC3477]. The existing definition and usage continues to be 
supported as described in the next section. Subsequent sections 
describe new variants of the object (denoted by new Class Types), and 
additional information carried in the object by means of extensions. 


3.1.1. Existing Definition and Usage 


This document does not deprecate the mechanisms defined in [RFC3477] 
and [RFC4206]. Those procedures must continue to operate as 
described in Section 3.7. 


That means that the LSP_TUNNEL_INTERFACE_ID object with Class Type 1 
remains unchanged, and can be used to establish an LSP that will be 
advertised as an unnumbered TE link in the same instance of the IGP 
as was used to advertise the TE links that the LSP traverses (that 
is, as an FA). The procedure is unchanged and operates as summarized 
in Section 1.3.5. 


[RFC3477] does not make any suggestions about where in Path or Resv 
messages the LSP_TUNNEL_INTERFACE_ID object should be placed. See 
Section 3.5 for recommended placement of this object in new 
implementations. 


3.1.2. Unnumbered Links with Action Identification 
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined 
to carry an unnumbered interface identifier and to indicate into 
which instance of the IGP the consequent TE link should be 
advertised. This does not deprecate the use of C-Type 1. 


The format of the object is as shown below. 


C-NUM = 193, C-Type = 4 
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-+-+-+- 
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LSR’s 
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ii 2 3 
4 56. 7 8 9 O01. 23 A S657 8 0-1. 2° 3° 4-5 6 7 8 9-04 
tat—tatHtat—tatata tata ta tata tatatatatatatatatatatatatat-t 
LSR’s Router ID | 
toto tatatat—tatatata—ta ta tata tatatatatatatatatatatatatat-t 
Interface ID (32 bits) | 
tat—tatHtat—tatatatatatatatatatatatatatatatatatatatat-t-Ft 

ions Reserved 

toto tatHtat—tatata tata ta tata ta ta tata tatatatatatatatatat-t 
TLVs 3 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++eHeHeHMHMHMHM 


Router ID 


Unchanged from the definition in [RFC3477]. 


Interface ID 


Un 


Actio 


Th 
tr 


Th 
me 
on 


re 


Th 


P- 


T- 


changed from the definition in [RFC3477]. 
ns 
is field specifies how the LSP that is being set up is to be 


eated. 


e field has meaning only on a Path message. On a Resv 
ssage, the field SHOULD be set to reflect the value received 


the corresponding Path message, and it MUST be ignored on 
ceipt. 

e field is composed of bit flags as follows: 
+-+-+-+-+-+-+- 

| | IafB[R]T]e]| 

+-+-+-+-+-+-+- 


flag (Private) 

0 means that the LSP is to be advertised as a link according 
to the settings of the other flags. 

1 means the LSP is to form a private link and is not to be 
advertised in the IGP, but is to be used according to the 
settings of the other flags. 


flag (TE link) 

0 means that the LSP is to be used as a TE link. 

1 means that the LSP is not to be used as a TE link. It may 
still be used as an IP link providing a routing adjacency 
as defined by the R-flag. 
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R-flag (Routing adjacency) 
0 means that the link is not to be used as a routing 
adjacency. 
1 means that the link is to be used to form a routing 
adjacency. 


B-flag (Bundle) 
0 means that the LSP will not form part of a link bundle. 
1 means that the LSP will form part of a bundle. See Section 
3.3 for more details. 


H-flag (Hierarchy/stitching) 
The use of an LSP as an H-LSP or as an S-LSP is usually 
implicit from the network technologies of the networks and 
the LSP, but this is not always the case (for example, in PSC 
networks). 
0 means that the LSP is to be used as a hierarchical LSP. 
1 means that the LSP is to be used as a stitching segment. 


Other bits are reserved for future use. They MUST be set to 
zero on transmission and SHOULD be ignored on receipt. 


Note that all defined bit flags have meaning at the same time. 
An LSP that is to form an FA would carry the Actions field set 
to 0x00. That is: 


P=0 (advertised) 

T=0 (TE link) 

R=0 (not a routing adjacency) 

B=0 (not a bundle) 

H=0 (hierarchical LSP) 
Reserved 


The Reserved bits MUST be set to zero on transmission and 
SHOULD be ignored on receipt. 


TLVs 


Zero, one, or more TLVs may be present. Each TLV is encoded as 
follows: 
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Type (16 bits) 


The identifier of the TLV. Two type values are defined in 
this document: 


IGP Instance Identifier TLV 

Unnumbered Component Link Identifier TLV 
IPv4 Numbered Component Link Identifier TLV 
IPv6 Numbered Component Link Identifier TLV 


AUNE 


Length (16 bits) 


Indicates the total length of the TLV in octets, i.e., 4 + 
the length of the value field in octets. A value field 
whose length is not a multiple of four MUST be zero-padded 
so that the TLV is four-octet aligned. 


Value 
The data for the TLV padded as described above. 


If this object is carried in a Path message, it is known as the 
"Forward Interface ID" for the LSP that is being set up. On a Resv 
message, the object is known as the "Reverse Interface ID" for the 
LSP. 


Salega IPv4 Numbered Links with Action Identification 


A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined 
to carry an IPv4 numbered interface address. 


The format of the object is as shown below. 
C-NUM = 193, C-Type = 2 


0 1 2 3. 
Ode 2384, 25 26" F890. 2 BAS 6 E: 98 O E 854 6) BO» 0: aL 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +t 
IPv4 Interface Address | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +t 
Actions Reserved 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++ 
TLVs 2 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +t 


: +—+— + 


+ 
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IPv4 Interface Address 


The address assigned to the interface that the sender applies 
to this LSP. 


Actions 

See Section 3.1.2. 
Reserved 

See Section 3.1.2. 
TLVs 

See Section 3.1.2. 


If this object is carried in a Path message, it is known as the 
"Forward Interface ID" for the LSP that is being set up. On a Resv 
message, the object is known as the "Reverse Interface ID" for the 
LSP. 


3.104. IPv6 Numbered Links with Action Identification 


A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined 
to carry an IPv6 numbered interface address. 


The format of the object is as shown below. 
C-NUM = 193, C-Type = 3 


0 a 2 3 
OD 2634S 6 7! 86 90. Wy (2: 3.4 6 28 OO) 12 34.9 6. 7! 28 901 
tata ta tata tata ta tata ta tata tata ta tata ta tata ta tata ta tata HMH 

| IPv6 Interface Address (128 bits) 

tata ta tate tata ta tata ta tata ta tata tata ta ta tata tata ta ta tata ta tatatat 
| IPv6é Interface Address (continued) 

tata tata ta tata tartar ta ta tata tata ta tata ta ta tata tata HH 
| IPv6é Interface Address (continued) 

tata ta tata tata ta tata ta tata ta tata tata ta tata ta tata ta tata tata ta tata 
| IPv6 Interface Address (continued) 

tata tata ta tata ta tata tata ta ta tata ta tata HHHMH 
| Actions | Reserved 

tata tata tata ta ta tata ta tata ta tata ta tata HHHMH 
z TLVs ~ 
tata ta tata tata tarda ta tata ta tata ta tata ta tata ta tata tata tata tata tatat 
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IPv6 Interface Address 


The address assigned to the interface the sender applies to 
this LSP. 


Actions 

See Section 3.1.2. 
Reserved 

See Section 3.1.2. 
TLVs 

See Section 3.1.2. 


If this object is carried in a Path message, it is known as the 
"Forward Interface ID" for the LSP that is being set up. On a Resv 
message, the object is known as the "Reverse Interface ID" for the 
LSP. 


3.2. Target IGP Identification TLV 


If the LSP being set up is to be advertised as a link, the egress 
needs to know which instance of the IGP it should use to make the 
advertisement. The default in [RFC4206] and [RFC3477] is that the 
LSP is advertised as an FA, that is, in the same instance of the IGP 
as was used to advertise the TE links that the LSP traverses. 


In order to facilitate an indication from the ingress to the egress 
of which IGP instance to use, the IGP Identification TLV is defined 
for inclusion in the new variants of the LSP_TUNNEL_INTERFACE_ID 
object defined in this document. 


The TLV has meaning only in a Path message. It SHOULD NOT be 
included in the LSP_TUNNEL_INTERFACE_ID object in a Resv message and 
MUST be ignored if found. 


If the P-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID 
object in a Path message is clear (i.e., zero), this TLV indicates 
the IGP instance to use for the advertisement. If the TLV is absent, 
the same instance of the IGP should be used as is used to advertise 
the TE links that the LSP traverses. Thus, for an FA, the TLV can be 
omitted; alternatively, the IGP Instance TLV may be present and 
identify the IGP instance or carry the reserved value Oxffffffff. 
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If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID 
object in a Resv message is set (i.e., one) indicating that the LSP 
is not to be advertised as a link, this TLV SHOULD NOT be present and 
MUST be ignored if encountered. 


The TLV is formatted as described in Section 3.1.2. The Type field 
has the value 1, and the Value field has the following content: 


0 1 2 3 
01234567890123456789012345678<901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| IGP Instance Identifier 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


IGP Instance Identifier 


A 32-bit identifier assigned to each of the IGP instances within a 
network, such that ingress and egress LSRs have the same 
understanding of these numbers. This is a management 
configuration exercise outside the scope of this document. 


Note that the IGP Instance Identifier might be mapped from an 
instance identifier used in the IGP itself (such as section 2.4 of 
[RFC5340] for OSPFv3, or [OSPFv2-MI] for OSPFv2) as a matter of 
network policy. See [OSPF-TI] for further discussion of this 
topic in OSPF, and [ISIS-GENAP] for IS-IS. 


The value Oxffffffff is reserved to mean that the LSP is to be 
advertised in the same instance of the IGP as was used to 
advertise the TE links that the LSP traverses. 


3.3. Component Link Identification TLV 


If the LSP that is being set up is to be used as a component link in 
a link bundle [RFC4201], it is necessary to indicate both the 
identity of the component link and the identity of the link bundle. 
Furthermore, it is necessary to indicate how the link bundle (that 
may be automatically created by the establishment of this LSP) is to 
be used and advertised. 


If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID 
object is set, the other fields of the object apply to the link 
bundle itself. That is, the interface identifiers (numbered or 
unnumbered) and the other flags in the Actions field apply to the 
link bundle and not to the component link that the LSP will form. 


Furthermore, the IGP Instance Identifier TLV (if present) also 
applies to the link bundle and not to the component link. 
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In order to exchange the identity of the component link, the 
Component Link Identifier TLVs are introduced as set out in the next 
sections. If the B-flag is set in the Actions field of the 
LSP_TUNNEL_INTERFACE_ID object in the Path message, exactly one of 
these TLVs MUST be present in the LSP_TUNNEL_INTERFACE_ID object in 
both the Path and Resv objects. 


3.3.1. Unnumbered Component Link Identification 


If the component link is to be unnumbered, the Unnumbered Component 
Link Identifier TLV is used. The TLV is formatted as described in 

Section 3.1.2. The Type field has the value 2, and the Value field 
has the following content: 


0 1 2 3 
ODT 2.3% 41556: Sf 849.081) 23h ANB 60 Pe e OA E S a 6 le Be 9 Orc. 
ot atototata toto tata tate tate tototaotet ited tata tata tatetatetitetet 
| Component Link Identifier | 
ot ato to tato tata tata tata toto tata totat ita tata tata tatetatetitetet 


Component Link Identifier 


Unnumbered identifier that is assigned to this component link 
within the bundle [RFC4201]. 


3.3.2. IPv4 Numbered Component Link Identification 


If the component link is identified with an IPv4 address, the IPv4 
Numbered Component Link Identifier TLV is used. The TLV is formatted 
as described in Section 3.1.2. The Type field has the value 3, and 
the Value field has the following content: 


(0 of 2 3 
O2 3A 5 E i 890 T Qe Be A 5.6. FB 9 0 T 2 3A DE oF 890: L 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| IPv4 Address | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


IPv4 Address 


The IPv4 address that is assigned to this component link within 
the bundle. 
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3s 


3: 


Bi. 


4. 


3. IPv6 Numbered Component Link Identification 


If the component link is identified with an IPv6 address, the IPv6 
Numbered Component Link Identifier TLV is used. The TLV is formatted 
as described in Section 3.1.2. The Type field has the value 4, and 
the Value field has the following content: 


0 al 2 3 
O72. e Oe 8 9 OTs 2 8. A562 78: <9 ON Te De 8A 0 167-89 0 A 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
IPv6 Address | 
—t-+-t-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-t-4-4-t-4+-t-t-4-t-4-4t-t-4-4t-t-4+ 
IPv6 Address (continued) | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
IPv6 Address (continued) | 
—t-+-t-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-t-4+-4-4t-4+-t-4t-4-t-4-4-t-4-4-4-4+ 
IPv6 Address (continued) | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +H 


+— + — + —+— + 


IPv6 Address 


The IPv6 address that is assigned to this component link within 
the bundle. 


Link State Advertisement 

The ingress and egress of an LSP that is set up using the 
LSP_TUNNEL_INTERFACE_ID object MUST advertise the LSP as agreed in 
the parameters of the object. 

Where a TE link is created from the LSP, the TE link SHOULD inherit 
the TE properties of the LSP as described in [RFC5212], but this 


process is subject to local and network-wide policy. 


It is possible that an LSP will be used to offer capacity and 


connectivity to multiple other networks. In this case, multiple 
instances of the LSP_TUNNEL_INTERFACE_ID object are permitted in the 
same Path and Resv messages. Each instance MUST have a different IGP 


Instance Identifier. 


Note, however, that a Path or Resv message MUST NOT contain more than 
one instance of the LSP_TUNNEL_INTERFACE_ID object with C-Type 1, and 
if such an object is present, all other instances of the 
LSP_TUNNEL_INTERFACE_ID object MUST include an IGP Instance 
Identifier TLV with IGP Instance Identifier set to a value that 
identifies some other IGP instance (in particular, not the value 
Oxffffffff). 
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If the link created from an LSP is advertised in the same IGP 
instance as was used to advertise the TE links that the LSP 
traverses, the addresses for the new link and for the links from 
which it is built MUST come from the same address space. 


If the link is advertised into another IGP instance, the addresses 
MAY be drawn from overlapping address spaces such that some addresses 
have different meanings in each IGP instance. 


In the IGP, the TE Router ID of the ingress LSR is taken from the 
Tunnel Sender Address in the Sender Template object signaled in the 
Path message. It is assumed that the ingress LSR knows the TE Router 
ID of the egress LSR since it has chosen to establish an LSP to that 
LSR and plans to use the LSP as a TE link. 


The link interface addresses or link interface identifiers for the 
forward and reverse direction links are taken from the 
LSP_TUNNEL_INTERFACE_ID object on the Path and Resv messages, 
respectively. 


When an LSP is torn down through explicit action (a PathTear message 
or a PathErr message with the Path_State_Removed flag set), the 
ingress and egress LSRs SHOULD withdraw the advertisement of any link 
that the LSP created and that was previously advertised. The link 
state advertisement MAY be retained as a virtual link in another 
layer network according to network-wide policy [PCE-LAYER]. 


3.5. Message Formats 


[RFC3477] does not state where in the Path message or Resv message 
the LSP_TUNNEL_INTERFACE_ID object should be placed. 


It is RECOMMENDED that new implementations place the 
LSP_TUNNEL_INTERFACE_ID objects in the Path message immediately after 
the SENDER_TSPEC object, and in the Resv message immediately after 
the FILTER_SPEC object. 


All implementations SHOULD be able to handle received messages with 
objects in any order, as described in [RFC3209]. 


3.6. Error Cases and Non-Acceptance 


Error cases and non-acceptance of new object variants caused by back- 
level implementations are discussed in Section 3.7. 


An egress LSR that receives an LSP_TUNNEL_INTERFACE_ID object may 
have cause to reject the parameters carried in the object fora 
number of reasons as set out below. In all cases, the egress SHOULD 
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respond with a PathErr message with the error code as indicated in 
the list below. In most cases, the error will arise during LSP 
setup, no Resv state will exist, and the PathErr will cause Path 
state to be removed. Where the error arises after the LSP has been 
successfully set up, the PathErr SHOULD be sent with the 
Path_State_Removed flag [RFC3473] clear so that the LSP remains 
operational. 


The error cases identified are as follows and are reported using the 
new error code ’/LSP Hierarchy Issue’ (code 38) and the error values 
listed below. 


Error | Error | Error-case 
code | value | 
SS See 4+-----—-—-+---—------— - - - 
38 1 Link advertisement not supported 
38 2 Link advertisement not allowed by policy 
38 3 TE link creation not supported 
38 4 TE link creation not allowed by policy 
38 5 Routing adjacency creation not supported 
38 6 Routing adjacency creation not allowed by policy 
38 7 Bundle creation not supported 
38 8 Bundle creation not allowed by policy 
38 9 Hierarchical LSP not supported 
38 10 LSP stitching not supported 
38 11 Link address type or family not supported 
38 12 IGP instance unknown 
38 13 IGP instance advertisement not allowed by policy 
38 14 Component link identifier not valid 
38 15 Unsupported component link identifier address family 


When an ingress LSR receives an LSP_TUNNEL_INTERFACE_ID object on a 
Resv message, it may need to reject it because of the setting of 
certain parameters in the object. Since these reasons all represent 
errors rather than mismatches of negotiable parameters, the ingress 
SHOULD respond with a PathTear to remove the LSP. The ingress MAY 
use a ResvErr with one of the following error codes, allowing the 
egress the option to correct the error in a new Resv message, or to 
tear down the LSP with a PathErr with the Path_State_Removed flag 
set. An ingress that uses the ResvErr MUST take precautions against 
a protocol loop where the egress responds with the same 
LSP_TUNNEL_INTERFACE_ID object with the same (or different) issues. 
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Error | Error | Error-case 

code | value | 

EERE EEEE, +--+- 
38 TI Link address type or family not supported 
38 14 Component link identifier not valid 
38 15 Unsupported component link identifier address family 
38 16 Component link identifier missing 


3.7. Backward Compatibility 


The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a class 
number of 193. According to [RFC2205], this means that a node that 
does not understand the object SHOULD ignore the object but forward 


it, unexamined and unmodified. Thus, there are no issues with 
transit LSRs supporting the pre-existing or new Class Types of this 
object. 


A back-level ingress node will behave as follows: 


- It will not issue Path messages containing LSP_TUNNEL_INTERFACE_ID 
objects with the new Class Types defined in this document. 


- It will reject Resv messages containing LSP_TUNNEL_INTERFACE_ID 
objects with the new Class Types defined in this document as 
described in [RFC2205]. In any case, such a situation would 
represent an error by the egress. 


- It will continue to use the LSP_TUNNEL_INTERFACE_ID object with 
Class Type 1 as defined in [RFC3477]. This behavior is supported 
by back-level egresses and by egresses conforming to this document. 


- According to an informal survey, there is no significant deployment 
of numbered FA establishment following the procedures defined in 
[RFC4206] and set out in Section 1.3.6 of this document. It is 
therefore safe to assume that back-level ingress LSRs will not use 
this mechanism. 


A back-level egress node will behave as follows: 


- It will continue to support the LSP_TUNNEL_INTERFACE_ID object with 
Class Type 1, as defined in [RFC3477], if issued by an ingress. 


- It will reject a Path message that carries an 
LSP_TUNNEL_INTERFACE_ID object with any of the new Class Types 
defined in this document using the procedures of [RFC2205]. This 
will inform the ingress that the egress is a back-level LSR. 
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- It will not expect to use the procedures for numbered FA 
establishment defined in [RFC4206] and set out in Section 1.3.6 of 
this document. 


In summary, the new mechanisms defined in this document do not impact 
the method to exchange unnumbered FA information described in 
[RFC3477]. That mechanism can be safely used in combination with the 
new mechanisms described here and is functionally equivalent to using 
the new C-Type indicating an unnumbered link with target IGP instance 
identifier with the Target IGP Instance value set to Oxffffffff. 


The mechanisms in this document obsolete the method to exchange the 
numbered FA information described in [RFC4206] as described in 
Section 1.4.6. 


4. Security Considerations 


[RFC3477] points out that one can argue that the use of the extra 
interface identifier that it provides could make an RSVP message 
harder to spoof. In that respect, the minor extensions to the 
protocol made in this document do not constitute an additional 
security risk, but could also be said to improve security. 


It should be noted that the ability of an ingress LSR to request that 
an egress LSR advertise an LSP as a TE link MUST be subject to 
appropriate policy checks at the egress LSR. That is, the egress LSR 
MUST NOT automatically accept the word of the ingress unless it is 
configured with such a policy. 


Further details of security for MPLS-TE and GMPLS can be found in 
[RFC5920]. 


5. IANA Considerations 

5.1. New Class Types 
IANA maintains a registry of RSVP parameters called "Resource 
Reservation Protocol (RSVP) Parameters" with a sub-registry called 
"Class Names, Class Numbers, and Class Types". There is an entry in 
this registry for the LSP_TUNNEL_INTERFACE_ID object defined in 
[RFC3477] with one Class Type defined. 


IANA has allocated three new Class Types for this object as defined 
in Sections 3.1.2, 3.1.3, and 3.1.4 as follows: 
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5. 


J; 


2 


3. 


C-Type Meaning Reference 
2 IPv4 interface identifier with target [RFC6107] 
3 IPv6 interface identifier with target [RFC6107] 
4 Unnumbered interface with target [RFC6107] 
Hierarchy Actions 


Section 3.1.2 defines an 8-bit flags field in the 
LSP_TUNNEL_INTERFACE_ID object. IANA has created a new sub-registry 
of the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling 
Parameters" registry called the "Hierarchy Actions" sub-registry as 
follows: 


Registry Name: Hierarchy Actions 
Reference: [RFC6107] 
Registration Procedures: Standards Action 


Registry: 

Bit Number Hex Value Name Reference 

0-2 Unassigned 

3 0x10 Hierarchy/stitching (H) [RFC6107] 

4 0x08 Bundle (B) [RFC6107] 

5 0x04 Routing adjacency (R) [RFC6107] 

6 0x02 TE link (T) [RFC6107] 

7 0x01 Private (P) [RFC6107] 
New Error Codes and Error Values 


IANA maintains a registry of RSVP error codes and error values as the 
"Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry 
of the "Resource Reservation Protocol (RSVP) Parameters" registry. 


IANA has defined a new error code with value 38 as below (see also 
Section 3.6). 


Error Code Meaning 
38 LSP Hierarchy Issue [RFC6107] 


IANA has listed the following error values for this error code (see 
also Section 3.6). 
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6. 


7. 


7. 


T 


This Error Code has the following globally-defined Error 


Value sub-codes: 


Link advertisement not allowed by policy 


TE link creation not allowed by policy 
Routing adjacency creation not supported 
Routing adjacency creation not allowed by policy 
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Bundle creation not allowed by policy 


Link address type or family not supported 


IGP instance advertisement not allowed by policy 
Component link identifier not valid 


Unsupported component link identifier address 


1 = Link advertisement not supported 

BS 

3 = TE link creation not supported 

4= 

5 = 

-= 

7 = Bundle creation not supported 

8 = 

9 = Hierarchical LSP not supported 

10 = LSP stitching not supported 

11 = 

12 = IGP instance unknown 

13 = 

14 = 

15 = 

family 

16 = Component link identifier missing 
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